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Abstract 
This document describes the framework for an RFC Series and an RFC 
Editor function that incorporate the principles of organized 
community involvement and accountability that has become necessary as 


the Internet technical community has grown, thereby enabling the RFC 
Series to continue to fulfill its mandate. 
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Les 


Introduction 


The first Request for Comments (RFC) document was published in April 
of 1969 as part of the effort to design and build what we now know of 
as the Internet. Since then, the RFC Series has been the archival 
series dedicated to documenting Internet technical specifications, 
including both general contributions from the Internet research and 
engineering community as well as standards documents. 


As described in the history of the first 30 years of RFCs 
([RFC2555]), the RFC Series was created for the purpose of capturing 
the research and engineering thought that underlie the design of 
(what we now know of as) the Internet. As the Internet Engineering 
Task Force (IETF) was formalized to carry out the discussion and 
documentation of Internet standards, IETF documents have become a 
large part (but not the entirety) of the RFC Series. 


As the IETF has grown up and celebrated its own 20 years of history, 
its requirements for archival publication of its output have changed 
and become more rigorous. Perhaps most significantly, the IETF must 
be able to define (based on its own open consensus discussion 
processes and leadership directions) and implement adjustments to its 
publication processes. 


At the same time, the Internet engineering and research community as 
a whole has grown and come to require more openness and 
accountability in all organizations supporting it. More than ever, 
this community needs an RFC Series that is supported (operationally 
and in terms of its principles) such that there is a balance of: 


Oo expert implementation; 


o clear management and direction -- for operations and evolution 
across the whole RFC Series (whether originating in the IETF or 
not); and 


O appropriate community input into and review of activities. 


Today, there is confusion and therefore sometimes tension over where 
and how to address RFC issues that are particular to contributing 
groups (e.g., the IETF, the Internet Architecture Board (IAB), or 
independent individuals). It isn’t clear where there should be 
community involvement versus RFC Editor control; depending on the 
issue, there might be more or less involvement from the IAB, the 
Internet Engineering Steering Group (IESG), or the community at 
large. There are similar issues with handling RFC Series-wide issues 
-—- where to discuss and resolve them in a way that is balanced across 
the whole series. 
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For example, there are current discussions about Intellectual 
Property Rights (IPR) for IETF-generated documents, but it’s not 
clear when or how to abstract the portions of those discussions that 
are relevant to the rest of the RFC Series. Discussions of labeling 
(of RFCs in general, IETF documents in particular, or some 
combination thereof) generally must be applied on an RFC Series-—wide 
basis or not at all. Without an agreed-on framework for managing the 
RFC Series, it is difficult to have those discussions in a non- 
polarized fashion -- either the IETF dictating the reality of the 
rest of the RFC Series, or the RFC Series imposing undue restrictions 
on the IETF document series. 


As part of its charter (see Appendix A), the IAB has a responsibility 
for the RFC Editor. Acknowledging the IETF’s and the general 
Internet engineering and research community’s evolving needs, the IAB 
would like to see a future for the RFC Series that continues to meet 
its original mandate of providing the archival series for the 
technical research and engineering documentation that describes the 
Internet. 


With this document, the IAB provides the framework for the RFC Series 
and an RFC Editor function with the specific purpose of ensuring that 
the RFC Series is maintained and supported in ways that are 
consistent with the stated purpose of the RFC Series and the 
realities of today’s Internet research and engineering community. 

The framework describes the existing "streams" of RFCs, draws a 
roadmap of existing process documents already defining the 
implementation, and provides clear direction of how to evolve this 
framework and its supporting pieces through discussion and future 
document revision. 


Specifically, this document provides a brief charter for the RFC 
Series, describes the role of the RFC Editor, the IAB, and the IETF 
Administrative Support Activity (IASA) in a framework for managing 
the RFC Series, and discusses the streams of input to the RFC Series 
from the various constituencies it serves. 


2. RFC Series Mission 


The RFC Series is the archival series dedicated to documenting 
Internet technical specifications, including general contributions 
from the Internet research and engineering community as well as 
standards documents. 


RFCs are available free of charge to anyone via the Internet. 
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3. 


-2. IAB 


Roles and Responsibilities 


As this document sets out a revised framework for supporting the RFC 
Series mission, this section reviews the updated roles and 
responsibilities of the entities that have had, and will have, 
involvement in continued support of the mission. 


1. RFC Editor 


Originally, there was a single person acting as editor of the RFC 
Series (the RFC Editor). The task has grown, and the work now 
requires the organized activity of several experts, so there are RFC 
Editors, or an RFC Editor organization. In time, there may be 
multiple organizations working together to undertake the work 
required by the RFC Series. For simplicity’s sake, and without 
attempting to predict how the role might be subdivided among them, 
this document refers to this collection of experts and organizations 
as the "RFC Editor". 


The RFC Editor is an expert technical editor and series editor, 
acting to support the mission of the RFC Series. As such, the RFC 
Editor is the implementer handling the editorial management of the 
RFC Series, in accordance with the defined processes. In addition, 
the RFC Editor is expected to be the expert and prime mover in 
discussions about policies for editing, publishing, and archiving 
RFCs. 


In this model, the role of the IAB is to ensure that the RFC Series 
mission is being appropriately fulfilled for the whole community for 
which it was created. The IAB does not, organizationally, have 
comprehensive publishing or editorial expertise. Therefore, the role 
of the IAB as put forward in this document is focused on ensuring 
that principles are met, the appropriate bodies and communities are 
duly informed and consulted, and the RFC Editor has what it needs in 
order to execute on the material that is in their mandate. 


It is the responsibility of the IAB to approve the appointment of the 
RFC Editor and to approve the general policy followed by the RFC 
Editor. 


3. Operational Oversight 
The IETF Administrative Support Activity (BCP 101, [BCP101]) was 


created to provide administrative support for the IETF, the IAB, and 
the Internet Research Task Force (IRTF). In its role of supporting 
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the IAB, the IASA is tasked with providing the funding for and 
operational oversight of the RFC Editor. 


The IAOC (IETF Administrative Oversight Committee) is the oversight 
board of the IASA, and the IAD (IETF Administrative Director) is the 
chief actor for the IASA. 


The IAOC works with the IAB to identify suitable persons or entities 
to fulfill the mandate of the RFC Editor. 


The IAOC establishes appropriate contractual agreements with the 
selected persons or entities to carry out the work that will satisfy 
the technical publication requirements defined for the various RFC 
input streams (see Section 5.2). The IAOC may define additional 
operational requirements and policies for management purposes to meet 
the requirements defined by the various communities. 


In accordance with BCP 101, the IAOC provides oversight of the 
operation of the RFC Editor activity based on the established 
agreements. 


3.4. Policy Oversight 


The IAB monitors the effectiveness of the policies in force and their 
implementation to ensure that the RFC Editor activity meets the 
editorial management and document publication needs as referenced in 
this document. In the event of serious non-conformance, the IAB, 
either on its own initiative or at the request of the IAOC, may 
require the IAOC to vary or terminate and renegotiate the 
arrangements for the RFC Editor activity. 


4. Framework 


With the RFC Series mission outlined above, this document describes a 
framework for supporting 


o the operational implementation of the RFC Series, 
based on 

Oo public process and definition documents, 

for which there are 


o clear responsibilities and mechanisms for update and change. 
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Generally speaking, the RFC Editor is responsible for the operational 
implementation of the RFC Series. As outlined in Section 3.3, the 
IAD provides the oversight of this operational role. 


The process and definition documents are detailed below, including 
responsibility for the individual process documents (maintenance and 
update). The RFC Editor works with the appropriate community to 
ensure that the process documents reflect current requirements. The 
TAB is charged with the role of verifying that appropriate community 
input has been sought and that any changes appropriately account for 
community requirements. 


There are 3 categories of activity, and a 4th category of series-—wide 
rules and guidelines, described for implementing the RFC Series to 
support its mission: 

Oo Approval of documents. 

o Editing, processing, and publication of documents. 


o Archiving and indexing the documents and making them accessible. 


o Series rules and guidelines. 


.1. Document Approval 


The RFC Series mission implicitly requires that documents be reviewed 
and approved for acceptance into the series. 


1.1. Definition 


Section 5.1 describes the different streams of documents that are put 
to the RFC Editor for publication as RFCs today. While there may be 
general policies for approval of documents as RFCs (to ensure the 
coherence of the RFC Series), there are also policies defined for the 
approval of documents in each stream. Generally speaking, there is a 
different approving body for each stream. The current definitions 
are catalogued in Section 5.1. 


-1.2. Operational Implementation 


Each stream has its own documented approval process. The RFC Editor 
is responsible for the approval of documents in one of the streams 
(Independent Submission stream, see Section 5.1.4) and works with the 
other approving bodies to ensure smooth passage of approved documents 
into the next phases, ultimately to publication and archiving as an 
RFC. 
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4.1.3. Process Change 


From time to time, it may be necessary to change the approval 
processes for any given stream, or even add or remove streams. This 
may occur when the RFC Editor, the IAB, the body responsible for a 
given stream of documents, or the community determines that there are 
issues to be resolved in general for RFC approval or for per-stream 
approval processes. 


In this framework, the general approach is that the IAB will work 
with the RFC Editor and other parties to get community input and it 
will verify that any changes appropriately account for community 
requirements. 


4.1.4. Existing Approval Process Documents 


The existing documents describing the approval processes for each 
stream are detailed in Section 5.1. 


4.2. Editing, Processing, and Publication of Documents 


Producing and maintaining a coherent, well-edited document series 
requires specialized skills and subject matter expertise. This is 
the domain of the RFC Editor. Nevertheless, the community served by 
the RFC Series and the communities served by the individual streams 
of RFCs have requirements that help define the nature of the series. 


4.2.1. Definition 


General and stream-specific requirements for the RFC Series are 
documented in community-approved documents (catalogued in Section 5.2 
below). 


Any specific interfaces, numbers, or concrete values required to make 
the requirements operational are the subject of agreements between 
the IASA and the RFC Editor (e.g., contracts, statements of work, 
service level agreements, etc). 


4.2.2. Operational Implementation 


The RFC Editor is responsible for ensuring that editing, processing, 
and publication of RFCs are carried out in a way that is consistent 
with the requirements laid out in the appropriate documents. The RFC 
Editor works with the IASA to provide regular reporting and feedback 
on these operations. 
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4. 


-2.3. Process Change 


From time to time, it may be necessary to change the requirements for 
any given stream, or the RFC Series in general. This may occur when 
the RFC Editor, the IAB, the approval body for a given stream of 
documents, or the community determines that there are issues to be 
resolved in general for RFCs or for per-stream requirements. 


In this model, the general approach is that the IAB will work with 
the RFC Editor to get community input and it will approve changes by 
validating appropriate consideration of community requirements. 


.2.4. Existing Process Documents 


Documents describing existing requirements for the streams are 
detailed in Section 5.2. 


3. Archiving, Indexing, and Accessibility 


The activities of archiving, indexing, and making accessible the RFC 
Series can be informed by specific subject matter expertise in 
general document series editing. It is also important that they are 
informed by requirements from the whole community. As long as the 
RFC Series is to remain coherent, there should be uniform archiving 
and indexing of RFCs across all streams and a common method of 
accessing the resulting documents. 


-3.1. Definition 


In principle, there should be a community consensus document 
describing the archiving, indexing, and accessibility requirements 
for the RFC Series. In practice, we continue with the archive as 
built by the capable RFC Editors since the series’ inception. 


Any specific concrete requirements for the archive, index, and 
accessibility operations are the subject of agreements between the 
IASA and the RFC Editor (e.g., contracts, statements of work, service 
level agreements, etc). 


-3.2. Operational Implementation 


The RFC Editor is responsible for ensuring that the RFC archive and 
index are maintained appropriately and that the resulting documents 
are made available to anybody wishing to access them via the 
Internet. The RFC Editor works with the IASA for regular reporting 
and feedback. 
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4.3.3. Process Change 


Should there be a community move to propose changes to the 
requirements for the RFC archive and index or accessibility, the IAB 
will work with the RFC Editor to get community input and it will 
approve changes by validating appropriate consideration of community 
requirements. 


4.3.4. Existing Process Documents 
There are no applicable process documents. 

4.4. Series-Wide Guidelines and Rules 
The RFC Series style and content can be shaped by subject matter 
expertise in document series editing. They are also informed by 
requirements by the using community. As long as the RFC Series is to 
remain coherent, there should be uniform style and content for RFCs 
across all streams. This includes, but is not limited to, acceptable 
language, use of references, and copyright rules. 

4.4.1. Definition 
In principle, there should be a community consensus document (or set 
of documents) describing the content requirements for the RFC Series. 
In practice, some do exist, though some need reviewing and more may 
be needed over time. 


4.4.2. Operational Implementation 


The RFC Editor is responsible for ensuring that the RFC Series 
guidelines are upheld within the RFC Series. 


4.4.3. Process Change 


When additions or changes are needed to series-wide definitions, the 

TAB will work with the RFC Editor and stream stakeholders to get 

community input and review. The IAB will approve changes by 

validating appropriate consideration of community requirements. 
4.4.4. Existing Process Documents 

Existing series-wide rules and guidelines documents include: 


o Instructions to RFC Authors (RFC 2223 [RFC2223], [RFC2223BIS]) 


o Copyright and intellectual property rules (RFC 3978 [RFC3978] and 
RFC 4748 [RFC4748]) 
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Is 


o Normative references (RFC 3967 [RFC3967] and RFC 4897 [RFC4897]) 
RFC Streams 


Various contributors provide input to the RFC Series. These 
contributors come from several different communities, each with its 
own defined process for approving documents that will be published by 
the RFC Editor. This is nothing new; however, over time the various 
communities and document requirements have grown and separated. In 
order to promote harmony in discussing the collective set of 
requirements, it is useful to recognize each in their own space -- 
and they are referred to here as "streams". 


Note that by identifying separate streams, there is no intention of 
dividing them or undermining their management as one series. Rather, 
the opposite is true -- by clarifying the constituent parts, it is 
easier to make them work together without the friction that sometimes 
arises when discussing various requirements. 


The subsections below identify the streams that exist today. There 
is no immediate expectation of new streams being created and it is 
preferable that new streams NOT be created. Creation of streams and 
all policies surrounding general changes to the RFC Series are 
discussed above in Section 4. 


1. RFC Approval Processes 


Processes for approval of documents (or requirements) for each stream 
are defined by the community that defines the stream. The IAB is 
charged with the role of verifying that appropriate community input 
has been sought and that the changes are consistent with the RFC 
Series mission and this overall framework. 


The RFC Editor is expected to publish all documents passed to it 
after appropriate review and approval in one of the identified 
streams. 


ebela IETF Document Stream 


The IETF document stream includes IETF WG documents as well as 
"individual submissions" sponsored by an IESG area director. Any 
document being published as part of the IETF standards process must 
follow this stream -- no other stream can approve Standards-Track or 
Best Current Practice (BCP) RFCs. 
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Approval of documents in the IETF stream is defined by 


o the IETF standards process (RFC 2026 [RFC2026] and its 
successors). 


o the IESG process for sponsoring individual submissions [SPONSOR]). 


Changes to the approval process for this stream are made by updating 
the IETF standards process documents. 


5.1.2. IAB Document Stream 


The IAB defines the processes by which it approves documents in its 
stream. Consistent with the above, any documents that the IAB wishes 
to publish as part of the IETF Standards Track (Standards or BCPs) 
are subject to the approval processes referred to in Section 5.1.1. 


The review and approval process for documents in the IAB stream is 
described in 


o the IAB process for review and approval of its documents (RFC 4845 
[RFC4845]). 


5.1.3. IRTF Document Stream 
The IRTF is chartered as an activity of the IAB. With the approval 


of the IAB, the IRTF may publish and update a process for publication 
of its own, non-IETF Standards-Track, documents. 


The review and approval process for documents in the IRTF stream is 
described in 


o IRTF Research Group RFCs [IRTF-DOCS]. 

5.1.4. Independent Submission Stream 
The RFC Series has always served a broader Internet technical 
community than the IETF. The "Independent Submission" stream is 
defined to provide review and (possible) approval of documents that 
are outside the scope of the streams identified above. 
Generally speaking, approval of documents in this stream falls under 


the purview of the RFC Editor, and the RFC Editor seeks input to its 
review from the IESG. 
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The process for reviewing and approving documents in the Independent 
Submission stream is defined by 
o Independent Submissions to the RFC Editor (RFC 4846 [RFC4846]). 


o The IESG and RFC Editor Documents: Procedures (RFC 3932 
[RFC3932]). 


5.2. RFC Technical Publication Requirements 


The Internet engineering and research community has not only grown, 
it has become more diverse, and sometimes more demanding. The IETF, 
as a standards-developing organization, has publication requirements 
that extend beyond those of an academic journal. The IAB does not 
have the same interdependence with IANA assignments as the IETF 
stream does. Therefore, there is the need to both codify the 
publishing requirements of each stream, and endeavor to harmonize 
them to the extent that is reasonable. 


Therefore, it is expected that the community of effort behind each 
document stream will outline their technical publication 
requirements. 


As part of the RFC Editor oversight, the IAB must agree that the 
requirements are consistent with and implementable as part of the RFC 
Editor activity. 


BZ ds IETF Documents 
The requirements for this stream are defined in RFC 4714 [RFC4714]. 
5.2.2. IAB Documents 


Although they were developed for the IETF standards process, the IAB 
will identify the applicable requirements in RFC 4714 for its stream. 


If the IAB elects to define other requirements, they should deviate 
minimally from those (in an effort to keep the collective technical 
publication requirements reasonably managed by one technical 
publisher). 


5.2.3.  IRTF Documents 


Although they were developed for the IETF standards process, the IRTF 
will identify the applicable requirements in RFC 4714 for its stream. 


If the IRTF elects to define other requirements, they should deviate 
minimally from those (in an effort to keep the collective technical 
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publication requirements reasonably managed by one technical 
publisher). 


5.2.4. Independent Submissions 


Although they were developed for the IETF standards process, the RFC 
Editor will identify the applicable requirements in RFC 4714 for its 
stream. 


If the RFC Editor elects to define other requirements, they should 
deviate minimally from those (in an effort to keep the collective 
technical publication requirements reasonably managed by one 
technical publisher). 


6. Security Considerations 


The processes for the publication of documents must prevent the 
introduction of unapproved changes. Since the RFC Editor maintains 
the index of publications, sufficient security must be in place to 
prevent these published documents from being changed by external 
parties. The archive of RFC documents, any source documents needed 
to recreate the RFC documents, and any associated original documents 
(such as lists of errata, tools, and, for some early items, non- 
machine readable originals) need to be secured against failure of the 
storage medium and other similar disasters. 


7. IAB Members at the Time of Approval 


Bernard Aboba 
Loa Andersson 
Brian Carpenter 
Leslie Daigle 
Elwyn Davies 
Kevin Fall 

Olaf Kolkman 
Kurtis Lindqvist 
David Meyer 
David Oran 

Eric Rescorla 
Dave Thaler 
Lixia Zhang 
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Appendix A. A Retrospective of IAB Charters and RFC Editor 


With this document, the IAB’s role with respect to the RFC Series and 
the RFC Editor is being adjusted to work more directly with the RFC 
Editor and provide oversight to ensure the RFC Series mission 
principles and communities’ input are addressed appropriately. 


This section provides an overview of the role of the IAB with respect 
to the RFC Editor as it has been presented in IAB Charter RFCs dating 
back to 1992. The point of this section is that the IAB’s role has 
historically been substantive -- whether it is supposed to be 
directly responsible for the RFC Series’ editorial management (circa 
1992, Appendix A.1), or appointment of the RFC Editor organization 
and approval of general policy (circa 2000, Appendix A.3). 


Ale 1992 
[RFC1358] says: 


[The IAB’s] responsibilities shall include: 
Pie] 

(2) The editorial management and publication of the Request for 
Comments (RFC) document series, which constitutes the 
archival publication series for Internet Standards and 
related contributions by the Internet research and 
engineering community. 
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A.2. 1994 
[RFC1601] says: 
[The IAB’s] responsibilities under this charter include: 
(d) RFC Series and IANA 


The IAB is responsible for editorial management and publication of 
the Request for Comments (RFC) document series, and for 
administration of the various Internet assigned numbers. 


which it elaborates as 
2.4 RFC Series and Assigned Numbers 


The RFC Series constitutes the archival publication channel for 
Internet Standards and for other contributions by the Internet 
research and engineering community. The IAB shall select an RFC 
Editor, who shall be responsible for the editorial management and 
publication of the RFC Series. 


A.3. 2000 
[IABCHARTER], which is the most recent IAB Charter document, says: 
(d) RFC Series and IANA 


The RFC Editor executes editorial management and publication of the 
IETF "Request for Comment" (RFC) document series, which is the 
permanent document repository of the IETF. The RFC Series 
constitutes the archival publication channel for Internet Standards 
and for other contributions by the Internet research and engineering 
community. RFCs are available free of charge to anyone via the 
Internet. The IAB must approve the appointment of an organization to 
act as RFC Editor and the general policy followed by the RFC Editor. 
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